COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002		The design and manufacturing documentation of the foonly high speed
C00007 ENDMK
C⊗;
	The design and manufacturing documentation of the foonly high speed
processing unit has been completed, and further progress awaits ARPA's
decision to finance the manufacture.

	At Steve Crocker's request we have submitted a schedule and budget
for the completion of the machine.  This schedule and budget minimized
financial exposure through the period of completion of the hardware.  It
did not substantially overlap the software development required
 to turn the
machine into a network resource nor did it provide for the additional
hardware required to make the machine so usable.

	This is a response to your request to make a new plan to make foonly
available as a network resource including software, management, and operational
plan, and documentation.  Because the plan had to be prepared in three days
we have had to approximate a number of cost and schedule items.

	Making foonly available as a network resource involves the following
considerations.

	1. Foonly will be essentially a PDP-10 with 8 to 10 times the speed of
the KA-10 or 3 to 5 times the speed of the KI-10.  Besides this, user accessible
microcode will double the speed of some inner loops that the user or system
programmers choose to microcode.

	2. A machine of this performance used as a network resource makes
cost effective a large investment in memories and disk files since the same
amount of memory will do more computing with the faster processor.

	3. We will switch to the TENEX operating system, but we think we will have
to get some modifications made in order to get adequate performance and to
handle our special devices.  Naturally, we would like to get BBN to do as much
of the work as possible, and we would like these modifications to become official
parts of TENEX so others can use them and so we don't have to keep modifying
new releases of TENEX more than necessary.  We have not had sufficient recent
contact with TENEX development to say precisely what is required, but we
anticipate requirements in the following areas:

		3.1. Display handling.  The present TENEX is oriented towards
teletypes.  Everyone starts his work with displays by putting in facilities
for imitating teletypes on displays.  Certainly displays that imitate teletypes
are a big improvement on the teletypes themselves.  However, even for system
communication and editing, not to speak of applications that specifically
involve displaying such as graphics, this style of interaction is far from
optimal.  We have made some improvements in our system in this direction, but
a complete revision of display handling has been postponed, because we intend
to go to TENEX.  We are concerned that an attempt to agree on display
handling standards might lead to standardizing on a teletype imitation which
would be far from optimal.  We propose to play an active role in the discussions
on display handling in TENEX and over the network.

		3.2.